Communication hardware and software endeavor to provide mechanisms for favoring selected communication channels where the communication channels compete for common communication resources. The nature of these resources can vary widely among different communication architectures. Communication resource examples include bandwidth, message queues, interrupts, memory mappings, bus priority, and DMA processor time. In order to favor one communication channel over another, the communication architecture will provide mechanisms, and the corresponding methods for users to control these mechanisms, to favor the usage of key communication resources by the selected channel over other channels. Since these mechanisms and the methods to control the mechanisms allow manipulation of the communication service quality, they are referred to as Qualities of Service, or QoS. Because the nature of the communication resources varies widely, the resulting nature of the QoS capabilities of a communication architecture also varies widely.
Most real-time systems are distributed to some extent. A simple example of distribution is the communication of a CPU with one of its devices over a bus. More complex distributed systems enable nodes to communicate with other nodes over great distances through radio signals or networks.
Distributed systems that attempt to satisfy real-time constraints are subject to similar success criteria and obstacles. The goal of real-time middleware, including a real-time Object Request Broker (ORB), is to make both local and remote messages or “invocations” with end-to-end predictability. Distributed systems utilize processor time and resources within the communications hardware. The resources within the communications hardware can vary widely depending on the particular hardware architecture of an interprocessor communications scheme. The communications resources typically would include the available bandwidth for data communications, the dedicated processors involved in implementing the communications hardware, and any relay equipment (switches, cross bars, hubs, routers, bridges, gateways, etc.) in between the communications hardware on the communicating nodes.
Much research has been done and a corresponding rich theoretical foundation exists for both (i) scheduling processor time without regard for inter-node communications and (ii) scheduling inter-node communications and bandwidth without regard for processor time. While some research exists on coordinating the scheduling of inter-node communications with the scheduling of the central processors' nodes, there is little resulting theoretical foundation for helping schedule a specific distributed system or class of distributed systems.
Despite the absence of this theoretical foundation, distributed systems designers who are concerned with optimizing the timeliness goals of a distributed system are forced to make decisions on coordinating the scheduling of processor and communications resources. Typically scheduling decisions for resource areas, processors and communications, are locked into place early in the design of the distributed system. By allowing a distributed system designer to replace the logic used by an infrastructure communications software such as middleware, the designer can alter the scheduling coordination decisions through out and even after the development of the distributed system without changing the architecture or application source code of the system.
The Real-Time Common Object Request Broker Architecture (CORBA) specification defines the “end-to-end predictability” of timeliness in a fixed priority CORBA system as: respecting thread priorities between client and server for resolving resource contention during the processing of CORBA invocations; bounding the duration of thread priority inversions during end-to-end processing; and bounding the latencies of operation invocations.
CORBA is a standard developed by the Object Management Group® (OMG™) that allows interoperable distributed computing among the numerous hardware and software products available today. CORBA is essentially a design specification for an Object Request Broker (ORB). ORBs provide the mechanisms required for objects to communicate locally, on remote devices, written in different languages, or to different places on a network. For more information regarding CORBA, reference may be had to “The Common Object Request Broker: Architecture and Specification” which is continuously updated on the Internet at <www.omg.org>. Another ORB that is readily available on the market is ORBexpress™, which is developed by Objective Interfaces. ORBexpress™ is a high-performance, third-generation implementation of Common Object Request Broker Architecture (CORBA) technology.
Conventional systems however, do not allow application programmers to select a service level for a transport and to control communication channels, manage communication bandwidths, or schedule communications channels associated with the transport.